Skip to content

Binaryen-related micro optimizations#8257

Open
stevenwdv wants to merge 8 commits intoWebAssembly:mainfrom
stevenwdv:optimize
Open

Binaryen-related micro optimizations#8257
stevenwdv wants to merge 8 commits intoWebAssembly:mainfrom
stevenwdv:optimize

Conversation

@stevenwdv
Copy link

@stevenwdv stevenwdv commented Jan 31, 2026

This should shave a couple seconds off wasm-emscripten-finalize, which is really slow for me (more with source maps & stack overflow detection enabled, which I didn't look at here (yet)). Didn't make as much of a different as I'd hoped, but anyway.

  1. I'm doing this mostly without understanding the inner workings, focusing on the C++ side.
  2. Not sure what to do with third_party/llvm-project/dwarf2yaml.cpp, since it comes from LLVM. I did also submit dwarf2yaml.cpp optimizations llvm/llvm-project#179048 but their version is very different, and not only in the XXX BINARYEN areas.
  3. Please check that the removal of locationUpdater.has*() usages is correct. It seems that the result is almost identical. If the subtle difference is relevant, I can merge the two functions in a different way, wrapping in optional but also allowing 0 if the old location was found but the new wasn't.
  4. Maybe the Y.AbbrevDecls.reserve using the loop is a bit overkill since I think the performace impact was minimal, I can remove it if you want.

When built with -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_MIMALLOC=ON -DBYN_ENABLE_LTO=ON -DBUILD_STATIC_LIB=ON -DBYN_ENABLE_ASSERTIONS=OFF:

wasm-emscripten-finalize -g --bigint --no-dyncalls --no-legalize-javascript-ffi --dwarf thing.wasm -o thing-finalized.wasm --detect-features

Pre: 19s

flamegraph-pre

Post: 16.5s

flamegraph-post

It had negligible performance impact in the tested benchmark
@dschuff
Copy link
Member

dschuff commented Feb 13, 2026

Meta-comment: @kripken can correct me if I'm wrong here, but if your command line is
wasm-emscripten-finalize -g --bigint --no-dyncalls --no-legalize-javascript-ffi --dwarf thing.wasm -o thing-finalized.wasm --detect-features,
does that mean that the only reason you need wasm-emscripten-finalize in the first place is that you're not building your Emscripten code with bigint? e.g. if you use -sWASM_BIGINT=1 (or upgrade to a version of Emscripten that enables it by default), then maybe you wouldn't actually need to run wasm-emscripten-finalize at all. This would be especially good if you have DWARF.

@stevenwdv
Copy link
Author

stevenwdv commented Feb 13, 2026

@dschuff The full command that the compiler used actually also had --check-stack-overflow, and apparently you're right in that with -sNO_STACK_OVERFLOW_CHECK it doesn't call wasm-emscripten-finalize at all! I think I'll adopt that option by default... Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants